normalizace databazi adresare
Otázka od: Fitz Ladislav
19. 4. 2004 10:54
zdravim
delam novy projek jehoz soucasti je i jednoduchy adresar, chtel bych se
zeptap zda je lepsi psc a mesto dat primo do tabulky s firmou nebo do nejake
pomocne (je dost adres z jednoho mesta) a to same s ico a dic (spousta adres
to nema) nebo by to bylo uz moc normalizovane
database jsou Access a MSSQL
Odpovedá: Jakub Martinek
19. 4. 2004 11:37
> delam novy projek jehoz soucasti je i jednoduchy adresar,
> chtel bych se zeptap zda je lepsi psc a mesto dat primo do
> tabulky s firmou nebo do nejake pomocne (je dost adres z
> jednoho mesta) a to same s ico a dic (spousta adres to nema)
> nebo by to bylo uz moc normalizovane
>
> database jsou Access a MSSQL
U malych a zcela autonomnich apl. je asi lepsi pro vyhledani a vyber PSC
udrzovat samostatny ciselnik, ale jinak ukladat vse k firme (spousta firem
ma vlastni PSC). Pokud pouzijete UIR-ADR je vhodnejsi vyuzit jeho struktury
a v aplikaci osetrit vyjimky.
ICO a DIC nema take cenu udrzovat samostatne (pouzit varchar).
Jakub Martinek
jmartinek@vakmb.cz
Odpovedá: Slavomir Skopalik
19. 4. 2004 11:47
Spatny polozeny dotaz.
Slavek
PS: Musis specifikovat, jak se bude s daty zachazet a pak ti to vyjde
samo i bez poucek.
Napriklad pokud ocekavas, ze se budou casto prejmenovavat mesta, ulice
atd, tak by mely byt
normalizovane (aby se operace provedla jen jednou).
Nebo pokud budes vybirat firmy podle mesta atd.
Jen na zaklade dat se o tomm neda nic rici.
> zdravim
>
> delam novy projek jehoz soucasti je i jednoduchy adresar,
> chtel bych se zeptap zda je lepsi psc a mesto dat primo do
> tabulky s firmou nebo do nejake pomocne (je dost adres z
> jednoho mesta) a to same s ico a dic (spousta adres to nema)
> nebo by to bylo uz moc normalizovane
>
> database jsou Access a MSSQL
Odpovedá: Vlastimil Bardon
19. 4. 2004 13:33
Upozornuji na par skutecnosti:
1) Pod jednim PSC muze existovat vice obci - existuje ciselnik obci dosazitelny
tusim na ministerstvu vnitra - pres tento ciselnik pak lze jednoznacne nazvy
obci dostat, ale z PSC nikoli
2) Nevim o jaky adresar jde, ale obecne kazda firma muze mit nekolik adres.
Nejcasteji potrebujes adresy pro fakturaci a k tomu se vytvari tabulka
fakturacnich mist (s vazbou na firmu) a adresy pro dotucovani nejakych dodavek
a k tomu se vytvaru tabulka dodacich mist (s vazbou na firmu). Ale mohou
existovat i dalsi adresy (napriklad korespondencni)
3) Ne vzdy je nezbytne dodrzovat prisne normalizaci. Obecne plati, ze
normalizovany tvar je efektivnejsi pri zapisu udaju, denormalizovany pri
vyhledavani. Takze bys mel znat, kde budou vetsi naroky na vykon aplikace a
podle toho se rozhodovat. (Ja bych ale asi spise volil normalizovany tvar, je
to u me sila zvyku...)
-----Original Message-----
From: Slavomir Skopalik [mailto:skopalik@elektlabs.cz]
Sent: Monday, April 19, 2004 12:13 PM
>
> delam novy projek jehoz soucasti je i jednoduchy adresar,
> chtel bych se zeptap zda je lepsi psc a mesto dat primo do
> tabulky s firmou nebo do nejake pomocne (je dost adres z
> jednoho mesta) a to same s ico a dic (spousta adres to nema)
> nebo by to bylo uz moc normalizovane
>
> database jsou Access a MSSQL
Odpovedá: Fitz Ladislav
20. 4. 2004 8:59
jde o jednoduche vytvareni prodejek a faktur v radech par tisic (asi do
10tis) mesicne, tisk po vytvoreni, zmena adresy u radove jednoho dokladu z
1000, a nejake managerske vystupy (tech je jen minimum (radove asi 10) a
daji se spocitat dopredu
jinak diky za vsechny namety
Odpovedá: Slavomir Skopalik
20. 4. 2004 9:52
Jenom takova drobnost, faktury NESMI byt normalizovany,
jelikoz se nesmi zmena napriklad v adrese promitnou do historie !
Pokud se ti prestehuje odberatel, tak se to musi promitnout az do novych
faktur, stare se nesmi zmenit.
Pokud by k tomu doslo, tak by berni urad udelal sve.
Slavek
PS: Firma je vzdy definovana jmenem a sidlem, pokud
jedno z toho nesedi (pro dany cas), je doklad neplatny.
> jde o jednoduche vytvareni prodejek a faktur v radech par
> tisic (asi do
> 10tis) mesicne, tisk po vytvoreni, zmena adresy u radove
> jednoho dokladu z 1000, a nejake managerske vystupy (tech je
> jen minimum (radove asi 10) a daji se spocitat dopredu
>
> jinak diky za vsechny namety
>
>
>
>
>
>
Odpovedá: Vlastimil Bardon
20. 4. 2004 12:13
Myslim, ze to nebylo receno presne. Faktura musi mit svou adresu, ktera se
nesmi posleze menit. Ale v ramci te adresy muze byt odkaz treba na ciselnik
nazvu obci. Ovsem pokud se zmeni nazev obce, nemel by se menit zaznam v tom
ciselniku ale vytvorit novy klic s novym nazvem, aby byla zachovana historie.
Nicmene casto je opravdu nejlepsim resenim nechat ty nazvy obci primo ve
fakturach.
-----Original Message-----
From: Slavomir Skopalik [mailto:skopalik@elektlabs.cz]
Sent: Tuesday, April 20, 2004 10:15 AM
Jenom takova drobnost, faktury NESMI byt normalizovany,
jelikoz se nesmi zmena napriklad v adrese promitnou do historie !
Pokud se ti prestehuje odberatel, tak se to musi promitnout az do novych
faktur, stare se nesmi zmenit.
Pokud by k tomu doslo, tak by berni urad udelal sve.
Slavek
PS: Firma je vzdy definovana jmenem a sidlem, pokud
jedno z toho nesedi (pro dany cas), je doklad neplatny.
Odpovedá: Petr Zahradnik
20. 4. 2004 12:54
Puvodni zprava ze dne 20.4.2004:
> Jenom takova drobnost, faktury NESMI byt normalizovany,
> jelikoz se nesmi zmena napriklad v adrese promitnou do historie !
> Pokud se ti prestehuje odberatel, tak se to musi promitnout az do novych
> faktur, stare se nesmi zmenit.
> Pokud by k tomu doslo, tak by berni urad udelal sve.
Pokud si ty faktury tisknes na papir, tak v tom nevidim problem,
protoze berni urad, rikejme mu Financni urad, kontroluje papirove
doklady a nikoliv zaznamy v pocitaci. Kdyz bude dzungle v pocitaci,
ale na papire to bude spravne, nic se nedeje ve vztahu k FU.
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================
Odpovedá: Slavomir Skopalik
20. 4. 2004 13:14
>
> Pokud si ty faktury tisknes na papir, tak v tom nevidim
> problem, protoze berni urad, rikejme mu Financni urad,
> kontroluje papirove doklady a nikoliv zaznamy v pocitaci.
> Kdyz bude dzungle v pocitaci, ale na papire to bude spravne,
> nic se nedeje ve vztahu k FU.
Souhlas, bohuzel jen do doby, kdy potrebujes vytisknout kopii faktury,
nebo dodaciho listu 
.
Slavek
Ing. Slavomir Skopalik
Jednatel spolecnosti
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
--------------------------------------------
Mobil: 724 207 851
e-mail:skopalik@elektlabs.cz
http://www.elektlabs.cz
Odpovedá: Vlastimil Bardon
20. 4. 2004 14:00
Co se tyce financaku nebo auditora, tak by mu papiry mely stacit. Ale co kdyz
budes chtit delat nejake historicke analyzy, treba kolik jsi toho prodal po
okresech ci jednotlivych obcich? Ja bych se te historie radeji drzel, ikdyz je
pravda, ze se muze stat, ze ji potrebovat nikdy nebudes. Ale lepsi je mit co
nepotrebuju nez nemit co potrebuju.
-----Original Message-----
From: Petr Zahradnik [mailto:clexpert@clexpert.cz]
Sent: Tuesday, April 20, 2004 1:37 PM
Pokud si ty faktury tisknes na papir, tak v tom nevidim problem,
protoze berni urad, rikejme mu Financni urad, kontroluje papirove
doklady a nikoliv zaznamy v pocitaci. Kdyz bude dzungle v pocitaci,
ale na papire to bude spravne, nic se nedeje ve vztahu k FU.
Petr Zahradnik, pocitacovy expert
Odpovedá: Petr Zahradnik
20. 4. 2004 15:34
Puvodni zprava ze dne 20.4.2004:
> Co se tyce financaku nebo auditora, tak by mu papiry mely stacit.
> Ale co kdyz budes chtit delat nejake historicke analyzy, treba kolik
> jsi toho prodal po okresech ci jednotlivych obcich? Ja bych se te
> historie radeji drzel, ikdyz je pravda, ze se muze stat, ze ji
> potrebovat nikdy nebudes. Ale lepsi je mit co nepotrebuju nez nemit
> co potrebuju.
V tom ja s Tebou plne souhlasim. Nejlepsi je nemit v databazi bordel,
to je preci naprosto logicke. Pouze jsem si dovolil nesouhlasit s tim
FU, o nic vic neslo 
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================
Odpovedá: Ludek ZITA
21. 4. 2004 1:54
On Behalf Of Vlastimil Bardon
> Co se tyce financaku nebo auditora, tak by mu papiry mely
> stacit. Ale co kdyz budes chtit delat nejake historicke
> analyzy, treba kolik jsi toho prodal po okresech ci
> jednotlivych obcich? Ja bych se te historie radeji drzel,
> ikdyz je pravda, ze se muze stat, ze ji potrebovat nikdy
> nebudes. Ale lepsi je mit co nepotrebuju nez nemit co potrebuju.
>
Ahoj.
Jak uz tady nekdo napsal normalizace a klice jsou fajn na velikost
databaze a pro statistiky za mnoho let, ale evidence faktur (apod.)
konkretne jsou zrovna archivy a ne databaze takze reseni je nekolikere :
Nenormalizovat - ale pak je problem s realnou delko ruznych vypoctu a
statistik
Normalizovat a klicove udaje ukladat duplicitne v textovem tvaru (takze
ve fakture bude jak ID obce tak obec textove) - ale problem muze byt
velikost databaze
Normalizovat a udaje v ciselniku doplnit casovou platnosti - to ovsem
zase trochu komplikuje datovy model a pri nevhodne zvolenem DM to muze
vest opet k problemum se statistikou a rychlosti operaci nad DB
No a jeste jeden - tvrde normalizovat a archivovat "tiskovy" tvar
dokumentu mimo provozni databazi (TXT,XML,HTML,PDF,bitmapa...).
Zatim to neni bezne ale myslim, ze to ma velkou budoucnost, protoze pak
je mozne takovehle dokumenty "kolkovat" casovym razitkem a uplne tim
nahradit papirove dokumenty. (v Evrope to uz jde , v nasi drahe
socialisticko-krestanske-us vlasti jen teoreticky)
Ludek
Odpovedá: Pavel Malinsky
21. 4. 2004 3:15
> -----Original Message-----
> From: delphi-l-owner@clexpert.cz
> [mailto:delphi-l-owner@clexpert.cz] On Behalf Of Slavomir Skopalik
> Sent: Tuesday, April 20, 2004 10:15 AM
> To: delphi-l@clexpert.cz
> Subject: Re: normalizace databazi adresare
>
> Jenom takova drobnost, faktury NESMI byt normalizovany,
> jelikoz se nesmi zmena napriklad v adrese promitnou do historie !
> Pokud se ti prestehuje odberatel, tak se to musi promitnout
> az do novych
> faktur, stare se nesmi zmenit.
> Pokud by k tomu doslo, tak by berni urad udelal sve.
Ahoj,
spravne, zkusim to rict trochu jinak, jak to mam treba ja.
Mam tabulku odberatelu kde jsou unikatni veci (ICO, DIC, Nazev apod.)
potom mam tabulku kde ke kazdemu odberateli muze existovat
X adres (sidlo firmy, provozvna 1apod.). Pri zalozeni
faktury uzivatel rekne na kterou adresu fakturu vystavuje a
tyto udaje jsou zapsany PRIMO k zaznamu faktury, nikoliv , ze se dotahuji.
Coz prave splnuje vyse uvadeny pozadavek.
S pozdravem a dikem
=====================================
> Pavel Malinsky; malinsky@pmcom.cz <
=====================================
> GSM: 602 652 203 | ICQ: 322015967 <
=====================================
Odpovedá: Karel Rys
21. 4. 2004 6:54
Ludek ZITA dne 21 Apr 2004 v 2:48:
> No a jeste jeden - tvrde normalizovat a archivovat "tiskovy" tvar
> dokumentu mimo provozni databazi (TXT,XML,HTML,PDF,bitmapa...). Zatim
> to neni bezne ale myslim, ze to ma velkou budoucnost, protoze pak je
> mozne takovehle dokumenty "kolkovat" casovym razitkem a uplne tim
> nahradit papirove dokumenty. (v Evrope to uz jde , v nasi drahe
> socialisticko-krestanske-us vlasti jen teoreticky)
Nebrecte, i u nas jsou financni urady ochotny prijmout doklady v PDF. Dle slov
zakaznika na
blyskajici se CD sice urednice-skoro_duchodkyne vytrestily oci a poprosily, zda
by jeste mohly
dostat doklady ke kontrole DPH i v papirove forme, ale pristi mesic jiz pry
pujde bez problemu i
CD...
Jinak k puvodnimu dotazu: u dokladu ukladam jak odkaz do tabulky odberatelu
(pro dlouhodobe
statistiky), tak textove vsechny udaje z adresy, ICO a DIC. Tech par tisic
dokladu za rok
nezpusobi takovy narust databaze, abych riskoval problemy (napr. i zmena
formatu DIC tak nyni
neovlivni stare doklady apod.).
Karel Rys
Odpovedá: Fitz Ladislav
21. 4. 2004 9:58
takze abych to nejak shrnul asi nejvyhodnejsi (z hlediska moznosti prace a
minima problemu s urady) je mit tabulku firem s nazvem, ico, dic a k ni
tabulku adres ulice, mesto, psc, telefon, ...
jak resite pokud to mate takhle to ze ta sama firma nakupuje na ruznych
strediscich (napada me napr drahy) s jejich svazanim pod jednu firmu s
ruznymi adresami (pokud teda nechci replikovat vsechny adresy na vsechny
strediska coz se mi jevi jako zbytecne)
v dokladu potom mit odkaz na danou adresu a pres ni i na firmu a navic i
textove vyjadreni adresy pro eventuelni tisk
Odpovedá: Erik Salaj, Winsoft
21. 4. 2004 10:33
> takze abych to nejak shrnul asi nejvyhodnejsi (z hlediska moznosti prace a
> minima problemu s urady) je mit tabulku firem s nazvem, ico, dic a k ni
> tabulku adres ulice, mesto, psc, telefon, ...
> jak resite pokud to mate takhle to ze ta sama firma nakupuje na ruznych
> strediscich (napada me napr drahy) s jejich svazanim pod jednu firmu s
> ruznymi adresami (pokud teda nechci replikovat vsechny adresy na vsechny
> strediska coz se mi jevi jako zbytecne)
>
> v dokladu potom mit odkaz na danou adresu a pres ni i na firmu a navic i
> textove vyjadreni adresy pro eventuelni tisk
uz tu niekto spominal, ze mozes doplnit casovu platnost zaznamov,
to je IMHO najlepsie riesenie
Erik
Odpovedá: Slavomir Skopalik
21. 4. 2004 10:53
Fakturacni adresa je jen jedna, takze zadny problem.
Asi resis problem stredisek, tedy dodaci adresy.
Tech muze mit firma neomezene a mohou byt i docasne,
napriklad stavebni firma si necha posilat material tak kde
stavi nikoliv k sobe domu.
Doporucuji si nastudovat nektery z beznych ucetnich SW,
nebo si zajit do uctarny.
Slavek
> takze abych to nejak shrnul asi nejvyhodnejsi (z hlediska
> moznosti prace a minima problemu s urady) je mit tabulku
> firem s nazvem, ico, dic a k ni tabulku adres ulice, mesto,
> psc, telefon, ... jak resite pokud to mate takhle to ze ta
> sama firma nakupuje na ruznych strediscich (napada me napr
> drahy) s jejich svazanim pod jednu firmu s ruznymi adresami
> (pokud teda nechci replikovat vsechny adresy na vsechny
> strediska coz se mi jevi jako zbytecne)
>
> v dokladu potom mit odkaz na danou adresu a pres ni i na
> firmu a navic i textove vyjadreni adresy pro eventuelni tisk
>
Odpovedá: Fitz Ladislav
21. 4. 2004 11:55
> Asi resis problem stredisek, tedy dodaci adresy.
ne resim to ze ja mam nekolik stredisek a na jednotlivych strediscich si ta
sama firma akorat jine jeji strediska neco koupi a prave jak toto dat
dohromady
no ted co dela kdyz toodojde na moji centralu - nejak to spojit nebo to
nechat tak
kdyz si to spojim tak samozrejme by se to melo nejak promitnu i na patricne
klienty protoze asi vygeneruji novou vazbu na tuto firmu
Odpovedá: Slavomir Skopalik
21. 4. 2004 12:21
K tomu by melo slouzit ICO. To ze to koupi nejake stredisko neni
podstatne,
a ze se to koupi na nejakem stredisku take,
tedy pokud to neni dcerinna spolecnost, ale to je uz zase jina firma a
nelze
je davat do hromady (napriklad siemens).
Tady, pokud ovsem neresis vlastni OLAP, kdy se zajimas o strukture
odberatelu podlejinych kriterii.
Pak samozrejme te nezajima zmena nazvu, adresy atd.
Tohle by ale melo (se to dava) do jine DB, ktera slozi pouze
pro tyto ucely (ma jinou strukturu).
Slavek
> > Asi resis problem stredisek, tedy dodaci adresy.
>
> ne resim to ze ja mam nekolik stredisek a na jednotlivych
> strediscich si ta sama firma akorat jine jeji strediska neco
> koupi a prave jak toto dat dohromady
>
> no ted co dela kdyz toodojde na moji centralu - nejak to
> spojit nebo to nechat tak kdyz si to spojim tak samozrejme by
> se to melo nejak promitnu i na patricne klienty protoze asi
> vygeneruji novou vazbu na tuto firmu
>
Odpovedá: Vlastimil Bardon
21. 4. 2004 13:12
Trochu si to rozmysli, nez neco navrhnes. ICO nepouzivej jako klic (radeji
nikdy nepouzivej vyznamove polozky jako klic). Ale vzdy je to tak, ze jedna
firma muze mit nekolik fakturacnich mist a nekolik dodacich mist a nekolik
kontaktnich adres ... a kdovi co jeste. Takze to chce navrhnout nejakou
promyslenejsi strukturu s ohledem na budouci zivot Tve aplikace.
-----Original Message-----
From: Slavomir Skopalik [mailto:skopalik@elektlabs.cz]
Sent: Wednesday, April 21, 2004 1:07 PM
K tomu by melo slouzit ICO. To ze to koupi nejake stredisko neni
podstatne,
a ze se to koupi na nejakem stredisku take,
tedy pokud to neni dcerinna spolecnost, ale to je uz zase jina firma a
nelze
je davat do hromady (napriklad siemens).
Tady, pokud ovsem neresis vlastni OLAP, kdy se zajimas o strukture
odberatelu podlejinych kriterii.
Pak samozrejme te nezajima zmena nazvu, adresy atd.
Tohle by ale melo (se to dava) do jine DB, ktera slozi pouze
pro tyto ucely (ma jinou strukturu).
Odpovedá: Ludek ZITA
21. 4. 2004 14:16
On Behalf Of Slavomir Skopalik
> K tomu by melo slouzit ICO.
Ahoj.
Pouzit ICO(DIC) je IMHO VELMI_ HRUBA_CHYBA!!!
1) ICO (ac se to zda divne) NEMUSI byt v praxi jednoznacne
2) ICO(DIC) se muze zmenit a presto se jedna z marketingoveho i pravniho
hlediska (zavazky a pohledavky) o stejneho odberatele napriklad pokud
spolecnost zmeni pravni formu nebo pokud dojde ke slouceni spolecnosti
nebo v pripade nejake formy pravniho nastupnictvi.
DIC se meni napriklad pri stehovani sidla firmy. (mozna ted v tom novem
formatu uz ne), nicmene plati bod 2
Ludek
Odpovedá: Slavomir Skopalik
21. 4. 2004 15:39
> Ahoj.
> Pouzit ICO(DIC) je IMHO VELMI_ HRUBA_CHYBA!!!
To je omyl !!
Ja nikde nepsal, ze mas pouzit ICO jako PK, ale muzes
jej pouzit pro parovani, jelikoz pri opisovani adresy je
chyba temer jistotou.
Zakon rika tohle:
Firma je definovana jmenem a sidlem firmy.
Na OR to transaformuji do ICO.
Pokud budes delat zadavani faktury, tak bych jako
uzivatel ocekaval, ze zadam ICO a zobrazi se mi zaznam o firme. Preci nebudu
mit
ve firme jeste jeden ciselnik s prekladem ICO -> GUID
a vstupovat GUID ?
>
> 1) ICO (ac se to zda divne) NEMUSI byt v praxi jednoznacne
Prosim dokaz to. Pokud se to stane, tak je chyba na prislusnem OR
a firmy kterym se to stane budou mit dost problemu.
> 2) ICO(DIC) se muze zmenit a presto se jedna z marketingoveho
> i pravniho hlediska (zavazky a pohledavky) o stejneho
> odberatele napriklad pokud spolecnost zmeni pravni formu nebo
Jenze se pak jedna o jinou spolecnost !
Ze zakona:
treba ABC, a.s. -> ABC, s.r.o.
Tohle jsou ze zakona jine firmy, to ze si je sloucis pro sve interni potreby je
tva vec.
> pokud dojde ke slouceni spolecnosti nebo v pripade nejake
> formy pravniho nastupnictvi. DIC se meni napriklad pri
> stehovani sidla firmy. (mozna ted v tom novem formatu uz ne),
> nicmene plati bod 2
O DIC se tady nikdo nebavil, toco pises je snad samozrejme.
Slavek
Odpovedá: Ludek ZITA
21. 4. 2004 16:15
> -----Original Message-----
> > Ahoj.
> > Pouzit ICO(DIC) je IMHO VELMI_ HRUBA_CHYBA!!!
>
> To je omyl !!
> Ja nikde nepsal, ze mas pouzit ICO jako PK, ale muzes
> jej pouzit pro parovani, jelikoz pri opisovani adresy je
> chyba temer jistotou.
Jake "parovani" mas na mysli (parovani plateb nebo snad ...
<JOKE>uzivatelu a uzivatelek : 
</JOKE>
> Zakon rika tohle:
> Firma je definovana jmenem a sidlem firmy.
>
> Na OR to transaformuji do ICO.
>
> Pokud budes delat zadavani faktury, tak bych jako
> uzivatel ocekaval, ze zadam ICO a zobrazi se mi zaznam o
> firme. Preci nebudu mit ve firme jeste jeden ciselnik s
> prekladem ICO -> GUID a vstupovat GUID ?
No ja znam i uzivatele kteri ocekavaji neco jineho
Priklad z praxe : Jednoznacny klic subjektu =
1) v pripade drobnych odberatelu je to opravdu ICO
2) v pripade velkych siti a vyznacnych odberatelu je to nejaka zvolena
zkratka (napr. CZAHLOD, SKAHOLD, CZDELVITA)
3) v pripade zahranicnich spolecnosti je to obdobne napriklad JIMMY1,
HANNAH2 ....
Proste kazda firma ma jine potreby....
>
> >
> > 1) ICO (ac se to zda divne) NEMUSI byt v praxi jednoznacne
>
> Prosim dokaz to. Pokud se to stane, tak je chyba na
> prislusnem OR a firmy kterym se to stane budou mit dost problemu.
No jake problemy mas na mysli ?
V praxi jsem na to narazil jednou (bylo to tusim jedna firma odnekud z
Usti a druha blizko Brna ale bohuzel konkretni informace uz nejsem
schopen nijak dohledat a dolozit.)
Jinak z praxe je znamo a v archivu konference prijdes na to, ze podobna
situace je u rodnych cisel.
Na soukromy mail Ti posilam vypis z OR kdy nam zaregistovali firmu
s.r.o. se stejnym nazvem jako uz existujici a prisli jsme na to cirou
nahodou v bance pri zalozeni uctu
Takze tvoje duvera v statni rejstriky je prinejmensim problematicka.
> > 2) ICO(DIC) se muze zmenit a presto se jedna z marketingoveho i
> > pravniho hlediska (zavazky a pohledavky) o stejneho odberatele
> > napriklad pokud spolecnost zmeni pravni formu nebo
>
> Jenze se pak jedna o jinou spolecnost !
> Ze zakona:
> treba ABC, a.s. -> ABC, s.r.o.
>
> Tohle jsou ze zakona jine firmy, to ze si je sloucis pro sve
> interni potreby je tva vec.
No zalezi na tom z jakeho pohledu a podle ktereho zakona.
Napriklad zavazky a pohledavky mohou klidne mit pravni kontinuitu u
rozdilnych firem.
Takze to co rikas je takova samopravda ktera nema vubec zadny vliv na
vhodnost pouziti IC pro jednoznacnou identifikaci firmy v ramci
informacniho systemu.
Ludek
Odpovedá: Slavomir Skopalik
21. 4. 2004 19:54
> Jake "parovani" mas na mysli (parovani plateb nebo snad ...
> <JOKE>uzivatelu a uzivatelek : </JOKE>
Jestli jsem to spravne pochipil, tak se melo jednat o sestavy,
kolik ktera firma odebrala stahovane z ryznych pobocek.
>
> No ja znam i uzivatele kteri ocekavaji neco jineho
> Priklad z praxe : Jednoznacny klic subjektu =
> 1) v pripade drobnych odberatelu je to opravdu ICO
> 2) v pripade velkych siti a vyznacnych odberatelu je to
> nejaka zvolena zkratka (napr. CZAHLOD, SKAHOLD, CZDELVITA)
> 3) v pripade zahranicnich spolecnosti je to obdobne napriklad
> JIMMY1, HANNAH2 .... Proste kazda firma ma jine potreby....
Souhlas.
> > > 1) ICO (ac se to zda divne) NEMUSI byt v praxi jednoznacne
> >
> > Prosim dokaz to. Pokud se to stane, tak je chyba na
> > prislusnem OR a firmy kterym se to stane budou mit dost problemu.
>
> No jake problemy mas na mysli ?
Pri vyberu dani, jelikoz, pokud budou ze stejneho kraje, tak budou
mit i stejne ico a .... 
>
> V praxi jsem na to narazil jednou (bylo to tusim jedna firma
> odnekud z Usti a druha blizko Brna ale bohuzel konkretni
> informace uz nejsem schopen nijak dohledat a dolozit.) Jinak
> z praxe je znamo a v archivu konference prijdes na to, ze
> podobna situace je u rodnych cisel. Na soukromy mail Ti
> posilam vypis z OR kdy nam zaregistovali firmu s.r.o. se
> stejnym nazvem jako uz existujici a prisli jsme na to cirou
> nahodou v bance pri zalozeni uctu
Uz jsem to tu psal nekolikrat:
Jmeno firmy je k nicemu.
Zakon definuje, ze firma je urcena svym nazvem a sidlem a to cos
mi poslal proste byla jen shoda nazvu nic vic.
>
> Takze tvoje duvera v statni rejstriky je prinejmensim problematicka.
Pri vystavovani dokladu ti nic jineho nezbyva, musis respektovat
zakony i kdyz se ti to nelibi. Ja neresim identifikaci uvnitr DB,
to je trivialitka, ale identifikaci pri vstupu dat do systemu a vystupu
dat ze systemu.
> > Tohle jsou ze zakona jine firmy, to ze si je sloucis pro sve
> > interni potreby je tva vec.
>
> No zalezi na tom z jakeho pohledu a podle ktereho zakona.
> Napriklad zavazky a pohledavky mohou klidne mit pravni
> kontinuitu u rozdilnych firem. Takze to co rikas je takova
> samopravda ktera nema vubec zadny vliv na vhodnost pouziti IC
> pro jednoznacnou identifikaci firmy v ramci informacniho systemu.
Ja se opravdu nesnazim identifikovat uvnitr IS, ale mezi IS a na jeho
vstupu.
Prevod zavazku a pohledavek je neco jineho, to nesouvisi s fakturou,
novou fakturu vystavis na novou firmu, pohledavku budes uplatnovat vuci
subjektu, ktery je uveden na fakture jako odberatel.
Pokud se neco s firmou deje, tak nezaplacene faktury zustavaji v strare
spolecnosti a aktiva se prevedou.
Dotaz nebyl o jednoznacne identifikaci, tu bych pres ICO nedelal,
ale jak dat dohromady data z pobocek (tak jsem to pochopil).
Slavek
Odpovedá: Ludek ZITA
21. 4. 2004 21:37
] On Behalf Of Slavomir Skopalik
> Dotaz nebyl o jednoznacne identifikaci, tu bych pres ICO
> nedelal, ale jak dat dohromady data z pobocek (tak jsem to pochopil).
Ahoj.
No to je o cele konstrukci datoveho modelu adresare.
Musis oddelit adresy od firem a je to.
Adres pak muzes mit k firme prirazenych vic a jeste u nich muzes mit
vlastnost zda se jedna o dresy fakturacni, dodaci, neplatnou ....
Pripadne i casovou platnosti.
Dale predpokladam, ze faktura ma jednak identifikaci firmy a jedna
idetifikaci konecneho prijemce. Bez toho se fakturace snad ani neda
napsat.
Nejlepsi je neco takoveho :
Tabulka firem
ID_FIRMY (guid nebo autoincremet)
KOD unique textovy klic
Tabulka udaju
ID_UDAJFIRMY
ID_FIRMY
ID_TYPUUDAJE
dale
UDAJCISLO DECIMAL
UDAJTEXT VARCHAR
UDAJDATUM DATE
Nebo
UDAJ "VARIANT"
PLATIOD DATETIME
PLATIDO DATETIME
Tabulka typu
ID_TYPUDAJE
LABEL varchar
POPIS varchar
VLASTNOST int
Pripadne dalsi kratke idetifikatory vlastnosti udaju
V tabulce typu pak treba mas:
1 - Nazev - Obchodni jemeno firmy - NULL
2 - ICO - IC firmy - NULL
3 - DIC - DIC firmy -NULL
4 - Ulice - Ulice - 1 (fakturacni)
5 - Ulice - Ulice - 2 (dodaci)
6 - Ulice - Ulice - 3 (sidlo)
......
9999 - NOS - velikost nosu obchodniho zastupce -NULL
Pomoci toho popises co jde a jeste das uzivatelum moznost si krasne
dodavat svoje potrebna pole, navic podle typu se pak muzes v
uzivatelskem rozhrani k jedntlivym udajum stavet, pokud typ ID=124 bude
e-mail pak kliknutim spustis Outlook MAILTO, atd... Zrovna tak co se
tyce nabizenych ciselniku a pod, nese si to ssebou uz samotny udaj a je
jedno kolik mailu telefonu ci adres si uzivatel do adresare prida.
Jak spocitat pobocky je pak jiz jen select podle ID_TYP_UDAJE -->
ID_UDAJFIRMY --> ID_FIRMY
Ludek
Odpovedá: Slavomir Skopalik
21. 4. 2004 22:53
Bude to mit jedinnou vadu:
pokud budou vstupovat nove odberatele na pobockach (bez centralni
evidence
jak jsem pochopil), tak musi nekde dojit ke sparovani tech ID_FIRMY
(na kazde pobocce ma ta sama firma jine ID).
Tam jsem chtel pouzit to ICO, ale jestli mas lepsi reseni ?
Slavek
PS:Jeden muj odberatel to resi tak, ze je nutne se nejprve u nej
zaregistrovat
(trva to dost dlouho) a pak teprve muze clovek dodavat.
> Nejlepsi je neco takoveho :
>
> Tabulka firem
> ID_FIRMY (guid nebo autoincremet)
> KOD unique textovy klic
>
> Tabulka udaju
> ID_UDAJFIRMY
> ID_FIRMY
> ID_TYPUUDAJE
> dale
> UDAJCISLO DECIMAL
> UDAJTEXT VARCHAR
> UDAJDATUM DATE
> Nebo
> UDAJ "VARIANT"
> PLATIOD DATETIME
> PLATIDO DATETIME
>
> Tabulka typu
> ID_TYPUDAJE
> LABEL varchar
> POPIS varchar
> VLASTNOST int
> Pripadne dalsi kratke idetifikatory vlastnosti udaju
>
> V tabulce typu pak treba mas:
> 1 - Nazev - Obchodni jemeno firmy - NULL
> 2 - ICO - IC firmy - NULL
> 3 - DIC - DIC firmy -NULL
> 4 - Ulice - Ulice - 1 (fakturacni)
> 5 - Ulice - Ulice - 2 (dodaci)
> 6 - Ulice - Ulice - 3 (sidlo)
> ......
> 9999 - NOS - velikost nosu obchodniho zastupce -NULL
>
> Pomoci toho popises co jde a jeste das uzivatelum moznost si
> krasne dodavat svoje potrebna pole, navic podle typu se pak
> muzes v uzivatelskem rozhrani k jedntlivym udajum stavet,
> pokud typ ID=124 bude e-mail pak kliknutim spustis Outlook
> MAILTO, atd... Zrovna tak co se tyce nabizenych ciselniku a
> pod, nese si to ssebou uz samotny udaj a je jedno kolik mailu
> telefonu ci adres si uzivatel do adresare prida.
>
> Jak spocitat pobocky je pak jiz jen select podle ID_TYP_UDAJE
> --> ID_UDAJFIRMY --> ID_FIRMY
>
Odpovedá: Dalibor Faltynek
22. 4. 2004 8:34
Myslim, ze sparovani dat v takovychto pripadech je vec pro umelou
inteligenci, nebo spravce ciselniku. Na zaklade ica to sparovat asi nejde,
protoze pod jednim icem je vice pobocek nebo provozoven a jak rozhodnes,
ktera je ktera, kdyz pri zadavani nove firmy a sidla pobocky nekdo napise
treba do ulice o mezeru vic, takze sidla se jevi jako ruzna. To je ta krasa
centralnich databazi nepropojenych online. Ja bych to resil tak, ze upravu
hlavnich ciselniku (zbozi, skupiny a jine trideni)lze provadet jen centralne
a pokud je bezna prace offline, tak urcite ciselniky, kde to nejde, zavest
jako individualni.
Dalik.
> Bude to mit jedinnou vadu:
> pokud budou vstupovat nove odberatele na pobockach (bez centralni
> evidence
> jak jsem pochopil), tak musi nekde dojit ke sparovani tech ID_FIRMY
> (na kazde pobocce ma ta sama firma jine ID).
> Tam jsem chtel pouzit to ICO, ale jestli mas lepsi reseni ?
>
Odpovedá: Ludek ZITA
22. 4. 2004 9:38
On Behalf Of Slavomir Skopalik
> Bude to mit jedinnou vadu:
> pokud budou vstupovat nove odberatele na pobockach (bez
> centralni evidence jak jsem pochopil), tak musi nekde dojit
> ke sparovani tech ID_FIRMY (na kazde pobocce ma ta sama firma
> jine ID). Tam jsem chtel pouzit to ICO, ale jestli mas lepsi reseni ?
>
> Slavek
>
> PS:Jeden muj odberatel to resi tak, ze je nutne se nejprve u
> nej zaregistrovat (trva to dost dlouho) a pak teprve muze
> clovek dodavat.
Ahoj.
Tak to jsem zase nepochopil ja: 
, Pocital jsem s tim ze se jedna o
centralni evidenci.
Jinak udelat centralni evidenci replikovanou na Internetu je i pro tento
DM to prave protoze staci on-line replikovat pouze tu kratkou hlavni
tabulku ktera zajisti jedinecnost KOD_FIRMY a prideli unikatni ID_RIFMY
(v takovem pripade samozrejme guid.
Nic jineho nemusi na Inetu byt, ostatni se zreplikuje na centralu
nejakou davkou.
Ale to jsme se uz dostali strasne daleko a asi uplne jinam nez o co
puvodne slo.
Ludek
Odpovedá: Ludek ZITA
22. 4. 2004 9:37
On Behalf Of Dalibor Faltynek
> Myslim, ze sparovani dat v takovychto pripadech je vec pro
> umelou inteligenci, nebo spravce ciselniku. Na zaklade ica to
> sparovat asi nejde, protoze pod jednim icem je vice pobocek
> nebo provozoven a jak rozhodnes, ktera je ktera, kdyz pri
> zadavani nove firmy a sidla pobocky nekdo napise treba do
> ulice o mezeru vic, takze sidla se jevi jako ruzna. To je ta
> krasa centralnich databazi nepropojenych online. Ja bych to
> resil tak, ze upravu hlavnich ciselniku (zbozi, skupiny a
> jine trideni)lze provadet jen centralne a pokud je bezna
> prace offline, tak urcite ciselniky, kde to nejde, zavest
> jako individualni.
Ahoj.
To je pravda, ovsem v praxi je to obvykle tak, ze pobocky maji nejakou
identifikaci (napr. Hypernova 104)
Ludek
Odpovedá: Dalibor Faltynek
22. 4. 2004 10:17
Myslim, ze sparovani dat v takovychto pripadech je vec pro umelou
inteligenci, nebo spravce ciselniku. Na zaklade ica to sparovat asi nejde,
protoze pod jednim icem je vice pobocek nebo provozoven a jak rozhodnes,
ktera je ktera, kdyz pri zadavani nove firmy a sidla pobocky nekdo napise
treba do ulice o mezeru vic, takze sidla se jevi jako ruzna. To je ta krasa
centralnich databazi nepropojenych online. Ja bych to resil tak, ze upravu
hlavnich ciselniku (zbozi, skupiny a jine trideni)lze provadet jen centralne
a pokud je bezna prace offline, tak urcite ciselniky, kde to nejde, zavest
jako individualni.
Dalik.
> Bude to mit jedinnou vadu:
> pokud budou vstupovat nove odberatele na pobockach (bez centralni
> evidence
> jak jsem pochopil), tak musi nekde dojit ke sparovani tech ID_FIRMY
> (na kazde pobocce ma ta sama firma jine ID).
> Tam jsem chtel pouzit to ICO, ale jestli mas lepsi reseni ?
>
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email